Click Here!
home account info subscribe login search My ITKnowledge FAQ/help site map contact us


 
Brief Full
 Advanced
      Search
 Search Tips
To access the contents, click the chapter and section titles.

Wireless Networking Handbook
(Publisher: Macmillan Computer Publishing)
Author(s): Jim Geier
ISBN: 156205631x
Publication Date: 09/01/96

Bookmark It

Search this book:
 
Previous Table of Contents Next


Engineering

To provide support of difficult problems, particularly those that may lead to a network modification, have an engineering staff either in-house or available on a contract basis. The engineering staff should maintain knowledge of the inner workings of all network components and stay abreast of applicable network technologies.

Problems will normally come to the engineering group from maintenance or, in some cases, the help desk (see fig. 9.7). A user named Sally within a warehouse may call the help desk identifying that she is experiencing a great deal of delay accessing the inventory database from her wireless terminal. The help desk may hand the trouble call off to network management who runs tests and doesn’t find any network problems that could attribute to her delays. Network management may then hand the trouble call over to maintenance to do some lower level troubleshooting. For this case, maintenance runs some spectrum analysis checks and finds the presence of a periodic interfering radio signal. They hand the problem over to engineering to find a solution, which may require the repositioning of an access point.


Figure 9.7  Problem progression from a user to the engineering staff.

The previous example describes the reactive function of the engineering staff; however, engineering can play a significant proactive role as well by implementing a network reengineering methodology. Network reengineering, as shown in figure 9.8, constantly monitors factors that may influence you to modify the network, ensuring the network remains tuned to best meet the needs of the users.

Factors that may influence changes to the network include:

  Company relocations
  Reorganizations
  New applications and technologies

To perform modifications, you can use the overall network implementation process described in this book as a basis (see Chapters 5–10).


Figure 9.8  The network reengineering process.

Configuration Control

If nothing ever changed, life would be pretty boring. However, changes to the network, especially those not managed, can cause a great deal of headaches. The lack of proper control over changes to the network can result in stovepiping, where different portions of the company don’t coordinate with each other or anyone else for that matter and deploy systems and applications that are not interoperable. Providing interfaces that allow systems and users at these dissimilar sites to share information then becomes difficult, expensive, and perhaps impossible. Also, the lack of control over network implementations makes it difficult and costly to support the systems. For instance, you may end up with three different types of network operating systems and four different types of wireless LAN adapters to support. Centralized support would need to keep abreast of all of these product types, resulting in higher training costs.

As you prepare for the operational support of a company-wide system, establish a configuration control process as shown in figure 9.9. The design and installation of the system consists of hardware, software, documentation, procedures, and people. It’s paramount to consider the system implementation as a baseline, to be changed only when the person initiating the change follows the process. To implement this process, though, you need to identify those elements (configuration items) that are important to control.


Figure 9.9  The configuration control process.

The following identifies examples of configuration items you should consider incorporating as a basis for the configuration control process:

  Network interface adapter vendor
  Network operating system release
  Cabling standard
  Switch vendor and type
  Support plans

The description of these elements should be stored in a library accessible by the entire organization.

The person wanting to make changes to configuration items must submit a change request to the technical review panel (TRP) which will assess the technical nature of the change. The change request includes an evaluation of whether the change complies with the company’s technical standards. If the TRP feels the change is technically feasible, it forwards the request to the configuration control board (CCB) for final approval. The CCB mainly evaluates whether the project team has prepared for adequate levels of support for the implementation and coordinated the changes with the proper organizations. With approval of the change, the project team then must ensure the preparation of support documentation.

Documenting Plans for Operational Support

As with all phases of a project, documentation is important to convey the ideas from that phase to other project phases. In the case of operational support, a support plan is necessary to effectively carry out the support. An operational support plan describes how the organization will support the operational network. This plan should indicate which network elements require support and which organizations are going to support them; therefore, the plan should address all support elements this chapter describes. Figure 9.10 identifies the major elements of an operational support plan.


Figure 9.10  The major elements of an operational support plan.

Preparing for the Transfer to Operational Mode

The transfer of the system to operational mode should be very well defined. Otherwise, it’s not clear who is supporting the network, and “finger pointing” will occur if any problems arise. The main task of preparing for the transfer to operational mode is to develop a turnover agreement, outlined in figure 9.11, that will be put into effect after completing the installation and testing phase. At the beginning of the project, the project charter gave the project manager responsibility for implementing the network. The turnover agreement transfers this responsibility to the supporting organizations, the handling system administration, network management, and so on.


Figure 9.11  The outline of a turnover agreement.

The steps taken in this chapter will make the transition to an operational network smoother. With operational support ready to go, you are set to begin the installation phase.


Previous Table of Contents Next


Products |  Contact Us |  About Us |  Privacy  |  Ad Info  |  Home

Use of this site is subject to certain Terms & Conditions, Copyright © 1996-2000 EarthWeb Inc.
All rights reserved. Reproduction whole or in part in any form or medium without express written permission of EarthWeb is prohibited. Read EarthWeb's privacy statement.